Happy new year, everyone.

One of my goals for 2013 is to push JSR 347 into action again.  To kick start this, I propose a meeting among expert group members - anyone else with an interest in the JSR is welcome to attend as well.

Details are in my post to the mailing list.  Please respond to the mail list if you are interested in participating.

Cheers Manik

PCWorld has published an article on the recent data grid JSR that I have submitted.  As a follow-up to PCWorld’s article, I would like to make a few comments to clarify a few things.

I don’t quite understand what is meant by Red Hat’s approach not being the best solution.  Do people take issue with having a standard in the first place?  Or is it the standards body used in this particular case (the JCP)?  If it is the details of the standard itself, one should keep in mind that this has yet to be defined by an expert group!

It is unfortunate that the "others" mentioned in the article - who feel that Red Hat’s approach is not the best - were not able to provide any details about their objections. I would love to hear these objections and make sure that the JSR addresses them.

The importance of a standard, to remove vendor lock-in, etc., is pretty well understood, so I won’t go into too much detail here.  But with that in mind, I find Pandey’s comment regarding a "self-beneficial move" an odd one.  A standard makes it easier for people to switch between products (which may explain why no one else may have stepped up to the plate to propose such a standard thus far).  Proposing a standard makes it easier for end-users to move away from Infinispan.  Yes, it may help with awareness of Infinispan, but it also means Red Hat, just like other data grid vendors, will need to work really hard to make sure their products are up to scratch.  The only real beneficiary here is the end-user.  In fact, I’d like to invite Terracotta to participate in this JSR, as participation can only make it stronger, more relevant and eventually even more useful to end-users.

With regards to JSR-107, I believe Pandey has misunderstood the intention in proposing a data grid JSR.  I have proposed extending and building on top of JSR-107 - not throwing it away - and I have expressed this the JSR-107 expert group mailing list, of which Terracotta’s Greg Luck is a member.  In fact, without Pandey’s actually seeing my data grid proposal blog post - PCWorld’s article was written before I published details of the JSR submission, based on a high-level Red Hat press release - one has to wonder where such strong words come from!  :-)

Cheers Manik

In response to Antonio Goncalves' blog post on his wish list for Java EE 7 and particularly on his comments around the inactive JSR-107 JCACHE spec, I’d like to spend a few moments jotting down my thoughts on the subject.

To start with, I am on the JSR-107 expert group, representing Red Hat.  I have also been in recent discussions with the JCP about the inactive JSR and what can be done about it.

My feel is JSR-107 needs to be axed.  It’s been inactive for way too long, it is out of date, and the community is pretty jaded about it.  We do, however, need a JSR around distributed caches and in-memory data grids.  There is definitely a need in the Java EE 7 umbrella specification, particularly with increasing focus and alignment with cloud.  Apps designed to scale would almost certainly need a distributed, in-memory data grid.  If Java EE is to be the preferred platform to build Software-as-a-Service offerings, scalability is crucial.

So what should this data grid JSR look like?  Well, let’s start with JSR-107.  After all, I didn’t think there was anything wrong with JSR-107, just that it was too limiting/simplistic.

What’s in JSR-107? A quick summary:

What JSR-107 does not cover - but should be included in a Data Grid JSR Over and above what JSR-107 proposed, I believe the following features are crucial to a useful data grid standard:

JTA interoperability.  The ability to participate in transactions is necessary, both as an XA resource and as a simple cache to front a RDBMS, via JPA

Should play nice with JPA’s second level cache SPI

Define and mandate REPLICATION and DISTRIBUTION, as well as SYNCHRONOUS and ASYNCHRONOUS versions of network communications

These could be useful in the JSR, but needs more thought and discussion

Further interesting thoughts

These additional, NoSQL-like features would also be very interesting, but probably more sense in a later revision of this JSR - both for the sake of manageability as well as to allow more community adoption/feedback on such APIs.

I’d like to hear your thoughts and opinions around this - please comment away!

Cheers

Manik